New version! Users of older versions of BNDL Banger will be most interested in the following changes that are part of v.1.3:
1) Added a little bit of code to avoid a crash if just the right set of inits are installed. The crash isn't exactly my fault, but I'm the one that crashes and I can kludge around it, so I did. This crash would _ONLY_ show up if you selected the "Bang Something…" menu item from the "Banger" menu — and then ONLY if File Sharing was on _AND_ a certain commercially available extension was active.
2) Added a little bit of code to avoid hanging if the target volume was a server.
3) Cleaned up my heap a little, cutting out some fragmentation, wasting less space, etc.
4) (fixed in v.1.2) BNDL Banger now handles more than just applications (since more than just applications are likely to have a BNDL). Potential items to bang are filtered in the StandardGetFile dialog based on whether or not their "hasBundle" Finder info bit is set - if it's set, they show up in the StandardGetFile dialog. If it's NOT set, and you're using drag & drop, the file is simply ignored.
5) (fixed in v.1.2) Changed algorithm used in the "BangIt()" routine to a more reliable one. A side effect of this is that multiple beeps may be heard while banging an application. Version 1.0 only called PBDTRemoveAPPL() once (for the incoming application), but it should have been called once for each copy of the application with the same creator type that's found on the incoming application's volume. Now, there's one beep as each copy of an application is removed from the desktop database.
General description:
I've been endlessly annoyed by what a pain it can be to get the system to recognize changes you make to your app's icon, document icons, etc (all the stuff that's linked via the BNDL resource). CDev authors, INIT authors, Extension authors and many others have also probably been through this same hassle.
Without BNDL Banger, the best case situation (one hard drive, one copy of the app under development), still means you have to reboot _AND_ rebuild your desktop. On a large capacity drive (100megs and up), this takes a while and often discourages developers from making minor tweaks to icons (it's just not worth the hassle of rebuilding the desktop sometimes).
BNDL Banger is a little app that tricks the system into using your selected app's BNDL-related info ("tricks" = rips the old BNDL info out of the desktop database and gently coerces the new BNDL info back in...). It copes with the situation where you have multiple copies of your app laying around (using the BNDL from the copy of the app YOU requested) and eliminates the need to rebuild the desktop file (you do have to reboot though - there's practically no way to avoid that).
I did say "practically no way to avoid rebooting" — which means you can sort of avoid it. If you're just changing icons, then Get info on your application, click on the icon in the Info window, select COPY from the Edit menu, select PASTE from the Edit menu, select CUT from the edit menu — your new icon will probably show up now.
Why does this work? The Finder caches icons to help speed things up. When you selected PASTE, you gave the app a custom icon. Selecting CUT removed that icon and forced the Finder to re-read the app's actual icon (from the desktop database) instead of using the version it used to have cached. The same trick works for document icons, but you'll have to Get Info on each type of document that you want to trick the Finder into re-reading.
Sorry, but there's no way to automate this process (the Finder's current level of Apple event support doesn't come close to being able to allow something like this to be done via Apple events).
It's still a _LOT_ less hassle to just reboot. But, if you're determined not to reboot, you can force the Finder to restart by pressing Command-Option-Shift-Esc. Make sure all other apps have already been quit and make sure File Sharing is _OFF_ (or you can encounter other problems). Like I said, it's a LOT less hassle to just reboot. After all, the big time hit (rebuilding the desktop database) has been eliminated.
The only remaining "hole" is that if your BNDL to be banged lives on the boot volume AND another volume, but you bang the "other" volume's copy of the app, you'll still see the OLD information (because the boot volume is searched first, then the next volume, etc). You can have this problem any time you have more than one drive. This problem is addressed in "BNDL Banger Pro" which you can order from me for seven dollars (see the 'Read Me' file for details on the features in 'BNDL Banger Pro' and for information on where to send your seven dollars - complete Think C v.5.0.2 source code to both BNDL Banger v.1.3 and BNDL Banger Pro is included on the disk you get when you send your seven dollars).
BNDL Banger v.1.3 is FreeWare. BNDL Banger Pro is _NOT_ FreeWare (it's "commercial" and can't be uploaded). BNDL Banger Pro v.2.1 can be purchased by sending $7 (US) to:
Tim Swihart
Swihart's Software
P.O. Box 160643
Cupertino, CA 95016
Enjoy,
Tim S.
co-author, "Programming for System 7" (part of Addison Wesley's "Macintosh Inside
Out" series)
------ techie info below ------
Changes since version 1.2:
• Version number bumped to 1.3.
• Simplified HandleOAPP() to eliminate code that wasn't really needed. We saved
only a few bytes of memory, but every little bit helps.
• Added a filterProc to all calls to Alert(). The filterProc's sole goal in
life is to redraw the bold outline around the default button during update
events. Otherwise, it's possible to have part of the outline erased by
balloons that pop up on top of that bold outline. The system draws the
original bold outline, but doesn't bother to redraw it during updates. I
avoided most of this problem originally by carefully setting _MY_ balloons
to behave like menus (buffering and replacing the area they're drawn over),
but balloons posted by the system (like those that are put up for windows
in another layer) don't bother to restore the stuff they draw on top of.
Personally, I consider this lack of redrawing to be a system bug, but it's
been broken forever and nobody seems interested in fixing it. Since it makes
my app look bad, I'm kludging around it. This filterProc adds about a hundred
bytes to the size of the final app.
• Added an extra test while we're checking to see if the target volume can be banged.
Previously, we only looked to see if it had a desktop database, now we also check
to see if the target volume is NOT a server (servers can't be banged and thus do
NOT have a "suitable" desktop database). The change fixes the bug where BNDL
Banger would hang if it attempted to bang a file that lived on a server.
• "preload" removed from menu item resources to avoid fragmenting the heap.
• Modified FilterOutNonBNDLs() to handle the case where the incoming parm block
pointer is NIL (it should never be NIL, but with a certain third-party init installed
and File Sharing on, one of my Macs gets NIL for this pointer which caused a crash…).
• Removed call to MoreMasters() in Initialize() since I didn't really need more than
the default…
• Moved these notes from the various source files to the Read Me file. Now, we
don't have to wait for the compiler to wade through them and they're easier
to keep current (some of the files had redundant information in the notes, so
this also makes the whole thing a little smaller).
Changes since version 1.1:
• Version number bumped to 1.2.
• Renamed "Bang Application…" item in "Banger" menu to "Bang Something…". This
better reflects the fact that BNDL Banger now handles more than just applications
(since more than just applications are likely to have a BNDL resource). Potential
items to bang are filtered in the StandardGetFile dialog based on whether or not
their "hasBundle" is set - if it's set, they show up in the StandardGetFile
dialog. If it's NOT set, and you're using drag & drop, the file is simply ignored.
Credit for this idea goes to a fellow developer (thanks for the idea Cory!).
• Tweaked some balloon messages for clarity. All of these changes are in
the Balloons.r file.
• Reworded some of the text in the About box and the "tutorial" dialogs to reflect
the fact that BNDL Banger Pro can bang any file with a bundle instead of just
applications.
• Added call to InitCursor() when resuming after being sent to background. This
fixed the problem where you would occassionally have the wrong mouse pointer in
BNDL Banger and BNDL Banger Pro.
• Tweaked amount of RAM requested for "preferred" and "minimum" size partitions
under MultiFinder (we now use 60K, we could probably get by with less, so try
less if your system is tight on memory).
Changes since version 1.0:
• Version number bumped to 1.1.
• Fixed crash when launching under pre-System 7.0. The check for whether or not
we're running under System 7 was being done AFTER trying to append an item to
the Help menu, so I swapped the order of these two actions. The only routine
affected by this fix was "Initialize()".
• Corrected a comment in "Initialize()" to more accurately reflect what a called
routine was expected to do for us.
• Changed algorithm used in the "BangIt()" routine to a more reliable one. A side
effect of this is that multiple beeps may be heard while banging an application.
Version 1.0 only called PBDTRemoveAPPL() once (for the incoming application),
but it should have been called once for each copy of the application with the
same creator type that's found on the incoming application's volume. Now, there's
one beep as each copy of an application is removed from the desktop database. If
there are three copies of the application on the volume, three beeps are heard.
• Tweaked some of the balloon messages for clarity. All of these changes are in
